With the background of the situation in which the degree of dependency on online services of the society, economy and living increases, there has been an increasing importance of identity management which manages information relating to individuals and organizations. The identity management is a technique for promoting the security and convenience of the information relating to individuals and organizations in various services and systems, and managing the whole of the life cycle of an identity from registration to a change and deletion.
Here, the identity, in this context, refers to the whole of information which specifies an individual, a group, and an organization/company in a certain situation, and includes an identifier, credentials and attributes. The identifier is information for discriminating the identity, and corresponds to, for instance, an account or an employee number. The credentials are information for indicating the validity of some information content, and are, for instance, a password. The attributes are information which characterizes the identity, and refer to, for instance, a name, an address, and date of birth.
As a typical example of the technique utilizing such identity management, there is known Single Sign-On (hereinafter abbreviated as SSO). The SSO is a technique which enables use of a plurality of applications and services by a single authentication procedure. In many cases, the SSO integrates authentications which are provided in a plurality of applications in a single domain such as an intranet of one company. In this case, the SSO is generally realized by a method in which an authentication result is included in an HTTP Cookie and the authentication result is shared between the applications. In addition, such SSO methods have been individually manufactured as access management products by SI (System Integration) vendors or middleware vendors.
In recent years, there has been a demand for an SSO among different domains (hereinafter also referred to as cross-domains) across a single domain. A reason for this is outsourcing due to an acceleration of the consolidation and merger of companies, overseas expansion, and SaaS (Software as a Service) or the like in emerging cloud computing. For example, one of the merits of the SaaS or the like is quick use when needed.
However, when cross-domain SSO is realized, sharing of an authentication result is very time-consuming. There are two main causes. The first cause is that, since the use of HTTP Cookie is limited to a single domain, an authentication result cannot be shared between domains by using the HTTP Cookie. The second cause is that, since SSO methods of access management products, which are adopted for respective domains, are different among vendors, simple introduction is not possible and additional measures need to be prepared.
In order to resolve such causes, there has been an increasing demand for standardization of the SSO. One of typical standardization techniques, which meet such a demand, is SAML (Security Assertion Markup Language) which was formulated by a nonprofit organization, OASIS (Organization for the Advancement of Structured Information Standards).
The SAML is specifications in which the expression form of information relating to authentication, approval and attributes, and transmission/reception procedures are defined, and the SAML is systematically stipulated so as to realize various implementation modes in accordance with purposes. Subjects comprise three parties, i.e. an identity provider (hereinafter, abbreviated as IdP, and referred to as “ID provider”), a service provider (hereinafter, abbreviated as SP, and referred to as “service provider”), and a user. The SSO is realized by the service provider trusting an authentication result which is issued by the ID provider.
When the SSO based on SAML is started, the following two points, in general, need to be prepared in advance. The first point is that the relationship of trust should be established in advance by information exchange and consensus building in business and technical aspects between the service provider and ID provider. The second point is that one user should have individual accounts for respective service providers and should federate these individual SP accounts and the account of the ID provider in advance. The SSO cannot be started unless in a state in which advance preparations, such as the establishment of the relationship of trust and the advance account federation, have been completed.
After these advance preparations, the SSO is realized by the following procedures (1) to (6). Here, the procedures of the SSO through a Web browser are described.
(1) A user requests service provision from a service provider.
(2) Since the service provider has not yet authenticated the user, the service provider sends an authentication request to the ID provider via a user-side Web browser.
(3) The ID provider authenticates the user by some means, and creates an authentication assertion. Incidentally, the SAML does not stipulate the means for authentication, but stipulates a scheme for informing the service provider of an authentication assertion. The authentication assertion includes information, such as the kind of authentication means and the manner in which the credentials were created, in order for the service provider to determine whether the authentication result is trustworthy or not.
(4) The ID provider returns an authentication result including the created authentication assertion to the service provider via the user-side Web browser.
(5) The service provider determines permission/non-permission of service provision, based on the authentication result of the ID provider.
(6) The user receives service provision from the service provider.
In this manner, in the SSO that is based on SAML, a plurality of services are made usable by the user simply executing a one-time authentication procedure for the ID provider, without executing a further authentication procedure. At present, in order to secure interoperability of cross-domains, the middle vendor, which implemented the individual SSO system, sells access management products in which an SAML ID provider/service provider function is implemented, or introduces a commercial Web service in which an SAML service provider function is implemented.
In the meantime, in the SSO based on SAML, as described above, the advance account federation and registration are necessary. In usual cases, when a company uses a service which is provided by a service provider, an IS (Information System) department performs account registration and federation for the service provider.
The IS department collectively performs a large volume of advance processes corresponding to many users belonging to the company, or conducts, after a procedure through a serial approval flow at an arbitrary timing given by a user, the account registration and federation for this user.
Here, in the former case of executing the advance process, since there is no need to execute account registration and federation in the process of the SSO, there is no relation to the above-described data processing system.
On the other hand, in the latter case of the procedure through the approval flow, a great deal of time and labor is needed since the procedure is conducted through not only the user but also many people, such as superiors in layers of the organizational hierarchy to which the user belongs, and people in a procurement department and an IS department. Furthermore, since the IS department does not collectively perform the advance processes, manual operations occur, which are burdensome and are low in efficiency and convenience. For example, it is not possible to utilize the merit of quick use in SaaS, etc.
Accordingly, in the system which executes account registration and federation in the process of the SSO, it is preferable that the system has a seamless scheme for determining permission/non-permission of service use in a nonmanual manner.
Thus, there is a technique for automating a series processes from the application for use of services provided by a service provider to the SSO, by inserting, between the procedures (2) and (3) of the SSO, a process of executing account federation and registration after evaluating permission/non-permission of use of services provided by the service provider, based on a pre-defined policy relating to service use and the condition of service use.
The above-described technique has no problem in usual cases. However, according to the study by the inventor, there is room for improvement, as described below.
Usually, in a company, if a change in organization or personnel is made, the policy is updated from the standpoint of security. However, when a change in organization or personnel is made, it is necessary to conduct a handover work which follows the change in organization or personnel. If the policy is immediately updated without a manual operation, such a problem may occur that services, which are used in the handover work, cannot be utilized. Thus, in general, the update of the policy due to a change in organization or personnel is performed by a manual operation (i.e. the user performs a policy update work).
However, a manual work imposes a heavy load on the user, and there is a concern that a work error (human error) will occur.